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he  ability  to  access  information 
on  demand  at  any  location  confers  competitive  advantage  on 
individuals  in  an  increasingly  mobile  world.  As  users  become 
more  dependent  on  this  ability,  the  span  of  access  of  data 
repositories  will  have  to  grow.  The  increasing  social  accep¬ 
tance  of  the  home  or  any  other  location  as  a  place  of  work  is 
a  further  impetus  to  the  development  of  mechanisms  for 
mobile  information  access. 

These  considerations  imply  that  data  from  shared  file  sys¬ 
tems,  relational  databases,  object-oriented  databases,  and 
other  repositories  must  be  accessible  to  programs  running  on 
mobile  computers.  For  example,  a  technician  servicing  a  jet 
engine  on  a  parked  aircraft  needs  access  to  engineering 
details  of  that  model  of  engine  as  well  as  past  repair  records 
of  that  specific  engine.  Similarly,  a  businessman  who  is  contin¬ 
uing  his  work  on  the  train  home  from  M  anhattan  needs  access  to 
his  business  records.  Y  et  another  example  involves  emergency 
medical  response  to  a  case  of  poisoning:  the  responding  per¬ 
sonnel  will  need  rapid  access  to  medical  databases  describing 
poison  symptoms  and  antidotes,  as  well  as  access  to  the  spe¬ 
cific  patient's  medical  records  to  determine  drug  sensitivity. 
This  article  is  a  status  report  on  the  work  being  done  by 
my  colleagues  and  myself  toward  meeting  such  challenges.  It 
begins  by  describing  a  scenario  that  offers  a  tantalizing 
glimpse  of  the  power  of  mobile  information  access.  The  major 
obstacles  on  the  path  toward  this  vision  are  then  examined. 
The  rest  of  the  article  is  a  summary  of  research  on  overcom¬ 
ing  these  obstacles  in  the  context  of  the  Coda  and  Odyssey 
systems. 

A  Vision  of  Tomorrow 

I  magine  this  hypothetical  scenario  of  a  business  trip  in  the 
year  2000: 

You  are  sitting  at  your  office  desk,  editing  a  report  stored 
in  a  shared  file  system.  The  machine  you  are  using  is  a  small 
notebook  computer,  but  it  lets  you  use  the  larger  and  more 
comfortable  display  and  keyboard  on  your  desk  via  a  tabletop 
infrared  link.  Soon  it  is  time  to  leave  for  the  airport. 

When  the  limousine  arrives,  you  pick  up  your  notebook 
and  leave.  On  the  ride  to  the  airport  you  continue  your  work. 
Your  notebook  recognizes  that  it  is  no  longer  on  a  local  area 
network  (LAN),  but  continues  communication  with  the 
servers  via  a  cellular  modem.  You  finish  your  editing,  save  the 


file,  and  send  mail  to  your  coauthor  letting  him  know  that  he 
can  now  review  your  edits.  You  then  begin  working  on  the 
slides  for  your  talk  in  Paris.  Upon  arrival  at  the  airport,  you 
board  your  transatlantic  flight  and  continue  working. 
Although  each  seat  is  provided  with  an  outlet  for  air-to- 
ground  telephone  service,  your  notebook  inquires  and  discov¬ 
ers  that  telephone  charges  are  very  high.  1 1  therefore  wisely 
decides  to  let  you  operate  disconnected  and  to  defer  all  com¬ 
munication  until  you  have  landed. 

When  you  arrive  in  your  Paris  hotel  room,  your  notebook 
discovers  that  the  hotel's  late-night  telephone  charges  are  low, 
and  that  there  is  a  high-definition  television  (HDTV)  set  in 
your  room.  It  therefore  propagates  the  changes  you  have 
made  so  far,  fetches  new  versions  of  some  of  the  files  you  had 
cached,  picks  up  your  mail,  and  uses  the  H DTV  setasyour 
display.  You  work  late  into  the  night,  putting  the  finishing 
touches  on  your  slides.  The  next  morning,  you  present  your  talk. 
Your  notebook  senses  the  presence  of  a  large  wall -sized  dis¬ 
play  in  the  conference  room,  and  shows  your  slides  on  it. 
Since  your  talk  is  about  a  new  piece  of  user- interface  soft¬ 
ware,  you  are  able  to  give  a  live  demo  of  it  using  the  notebook. 

Once  your  business  is  complete,  you  decide  to  play  tourist 
for  a  day  before  returning  home.  The  concierge  at  your  hotel 
subscribes  you  to  an  excellent  guided  walking  tour,  and  rents 
you  a  heads-up  display  and  headphones.  Setting  out  with  your 
notebook  in  your  backpack,  you  pick  a  route  from  the  map 
displayed.  As  you  walk,  you  indicate  items  of  interest  on  the 
map.  A  short  video  describing  the  unique  historical  and  archi¬ 
tectural  features  of  the  site  is  seen,  and  the  accompanying 
audio  commentary  is  heard.  As  you  pass  through  a  major 
shopping  district,  advertisements  of  sales  (translated  by  your 
notebook  into  English)  pop  up  on  your  display. 

One  of  these  interests  you,  and  you  walk  into  the  store  and 
purchase  a  gift.  The  store  clerk  obtains  your  travel  itinerary 
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from  your  notebook  and  arranges  for  your  duty-free  purchase 
to  be  delivered  to  the  correct  gate  for  your  flight  home  tomorrow. 

You  continue  on  your  walking  tour  for  many  more  hours. 
Exhausted,  you  decide  to  take  the  metro  back  to  your  hotel. 
On  the  metro,  you  watch  CNN  on  your  notebook.  From  time 
to  time,  as  the  train  goes  through  regions  of  poor  reception, 
the  displayed  Image  degenerates  from  full-motion  color  to 
slow-scan  black-and-white. 

The  next  morning,  you  head  for  the  airport,  pick  up  your 
gift  at  the  gate,  and  board  the  flight  home.  You  can  relax  and 
watch  the  movie:  your  notebook  has  been  recording  your  pur¬ 
chases  and  is  now  automatically  preparing  an  expense  report. 
When  you  reach  home,  It  will  transmit  the  report  to  your  sec¬ 
retary  for  reimbursement. 

Adaptation:  The  Key  to 
Mobile  Information  Access 

hat  makes  this  scenario  fiction  rather  than  reality 
today?  Not  the  absence  of  proper  hardware,  since 
most  of  the  hardware  technologies  needed  are  close 
at  hand.  What  is  missing  isthe  software  support.  Developing 
this  software  is  the  goal  of  our  research. 

Constraints  of  Mobility 

O  ur  goal  is  made  challenging  by  four  fundamental  constraints 
of  mobility. 

Mobile  Elements  Are  Resource-Poor  Relative  to  Static  Ele¬ 
ments—  At  any  given  cost  and  level  of  technology,  considera¬ 
tions  of  weight,  power,  size,  and  ergonomics  will  exact  a 
penalty  in  computational  resources  such  as  processor  speed, 
memory  size,  and  disk  capacity.  W  hi le  mobile  elements  will 
undoubtedly  improve  in  absolute  ability,  they  will  always  be 
resource-poor  relative  to  static  elements. 

Mobility  Is  Inherently  Hazardous  —  A  Wall  Street  stockbro¬ 
ker  is  more  likely  to  be  mugged  on  the  streets  of  M  anhattan 
and  have  his  or  her  laptop  stolen  than  to  have  the  workstation 
in  a  locked  office  be  physically  subverted.  Even  if  security  is 
not  a  problem,  portable  computers  are  more  vulnerable  to 
loss  or  damage. 

Mobile  Connectivity  Is  Highly  Variable  in  Performance  and 
Reliability  —  I  nside  some  buildings,  a  mobile  element  may 
have  reliable,  high-speed  wireless  LAN  connectivity;  but  in 
other  buildings,  it  may  only  have  modem  or  integrated  ser¬ 
vices  digital  network  (ISDN)  connectivity.  0 utdoors,  it  may 
have  to  rely  on  a  low-bandwidth  wireless  wide  area  network 
(WAN)  with  gaps  in  coverage. 

Mobile  Elements  Rely  on  a  Finite  Energy  Source  —  While 
battery  technology  will  undoubtedly  improve  over  time,  the 
need  to  be  sensitive  to  power  consumption  will  not  diminish, 
Concern  for  power  consumption  must  span  many  levels  of 
hardware  and  software  to  be  fully  effective. 

These  constraints  are  not  just  artifacts  of  current  technolo¬ 


gy,  but  are  intrinsic  to  mobility.  T ogether,  they  complicate  the 
design  of  mobile  information  systems  and  require  us  to 
rethink  traditional  approaches  to  information  access.  I  n  addi¬ 
tion,  scalability  will  be  a  growing  concern  because  of  the  ubiq¬ 
uity  of  mobile  computers.  D  iversity  of  data  will  be  another 
key  concern  because  the  data  repositories  of  tomorrow  will  be 
much  richer  in  content  than  traditional  file  systems  or 
databases. 

The  Need  for  Adaptation 

M  obility  exacerbates  the  tension  between  autonomy  and  inter¬ 
dependence  that  is  characteristic  of  all  distributed  systems.  T o 
function  successfully,  mobile  elements  must  be  adaptive.  The 
relative  resource  poverty  of  mobile  elements,  as  well  as  their 
lower  trust  and  robustness,  argues  for  reliance  on  static 
servers;  but  the  need  to  cope  with  unreliable  and  low-perfor¬ 
mance  networks,  as  well  as  to  be  sensitive  to  power  consump¬ 
tion,  argues  for  self-reliance. 

A  ny  viable  approach  to  mobile  computing  must  strike  a 
balance  between  these  competing  concerns.  This  balance  can¬ 
not  be  a  static  one;  as  the  circumstances  of  a  mobile  client 
change,  it  must  react  and  dynamically  reassign  the  responsibil¬ 
ities  of  client  and  server. 

Taxonomy  of  Adaptation  Strategies 

The  range  of  strategies  for  adaptation  is  delimited  by  two 
extremes,  as  shown  in  Fig.  1.  At  one  extreme,  adaptation  is 
entirely  the  responsibility  of  individual  applications.  While  this 
laissez-faire  approach  avoids  the  need  for  system  support,  it 
lacks  a  central  arbitrator  to  resolve  incompatible  resource 
demands  of  different  applications  and  to  enforce  limits  on 
resource  usage.  It  also  makes  applications  more  difficult  to 
write,  and  fails  to  amortize  the  development  cost  of  support 
for  adaptation. 

At  the  other  extreme,  application-transparent  adaptation, 
the  responsibility  for  adaptation  is  borne  entirely  by  the  sys¬ 
tem.  This  approach  is  attractive  because  it  is  backward-com¬ 
patible  with  existing  applications:  they  continue  to  work  when 
mobile  without  any  modifications.  The  system  provides  the 
focal  point  for  resource  arbitration  and  control.  The  drawback 
of  this  approach  is  that  there  may  be  situations  in  which  the 
adaptation  performed  by  the  system  is  inadequate  or  even 
counterproductive  for  some  applications. 

Between  these  two  extremes  lies  a  spectrum  of  possibilities 
that  are  collectively  referred  to  as  application-aware 
adaptation.  By  supporting  a  collaborative  partnership  between 
applications  and  the  system,  this  approach  permits  individual 
applications  to  determine  how  best  to  adapt,  but  preserves  the 
ability  of  the  system  to  monitor  resources  and  to  enforce  allo¬ 
cation  decisions. 

We  have  been  exploring  application-transparent  adaptation 
since  about  1990.  Our  research  vehicle  has  been  the  Coda 
File  System,  a  descendant  of  the  Andrew  File  System 
(A  F  S)  [1],  M  ore  recently,  we  have  begun  exploration  of  appli¬ 
cation-aware  adaptation  in  Odyssey,  a  platform  for  mobile 
computing. 

Coda:  Application 
Tran  spa  ren  t  Ada  pta  tion 

Coda  is  an  experimental  file  system  whose  goal  is  to  offer 
clients  continued  access  to  data  in  the  face  of  server  and 
network  failures  [2],  It  inherits  many  of  the  usage  and 
design  assumptions  of  its  ancestor,  A  FS.  Clients  view  Coda  as 
a  single  location-transparent  shared  UNIX  file  system.  The 
Coda  namespace  is  mapped  to  individual  file  servers  at  the 
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granularity  of  subtrees,  called  vol¬ 
umes.  At  each  client,  a  cache  man¬ 
ager,  Venus,  dynamically  obtains 
and  caches  data  as  well  as  volume 
mappings. 

Disconnected  Operation 

Disconnected  operation,  a  concept 
first  conceived  and  demonstrated  in 
Coda,  is  an  important  initial  step  in 
mobile  computing  [3-5],  In  this 
mode  of  operation,  a  client  contin¬ 
ues  to  have  read  and  write  access 
to  data  in  its  cache  during  tempo¬ 
rary  network  outages.  T ransparency 
is  preserved  from  the  viewpoint  of 
applications  because  the  system 
bears  the  responsibilities  of  propa¬ 
gating  modifications  and  detecting 
update  conflicts  when  connectivity  is  restored. 

The  ability  to  operate  disconnected  can  be  useful  even 
when  connectivity  is  available.  F or  example,  disconnected 
operation  can  extend  battery  life  by  avoiding  wireless  trans¬ 
mission  and  reception.  It  can  reduce  communication  expense, 
an  important  consideration  when  rates  are  high.  It  allows 
radio  silence  to  be  maintained,  a  vital  capability  in  military 
applications.  A  nd,  of  course,  it  is  a  viable  fallback  position 
when  network  characteristics  degrade  beyond  usability. 

Cache  Management  —  T o  support  disconnected  operation, 
Venus  operates  in  one  of  three  states:  hoarding,  emulating, 
and  reintegrating,  as  shown  in  F  ig.  2.  V enus  is  normally  in  the 
hoarding  state,  relying  on  servers  but  always  on  the  alert  for 
possible  disconnection.  The  hoarding  state  is  so  named 
because  a  key  responsibility  of  V  enus  in  this  state  is  to  ensure 
that  critical  objects  are  cached  at  the  moment  of  disconnec¬ 
tion.  U  pon  disconnection,  V  enus  enters  the  emulating  state 
and  remains  there  for  the  duration  of  disconnection.  U  pon 
reconnection,  V  enus  enters  the  reintegrating  state,  resynchro¬ 
nizes  its  cache  with  the  servers,  and  then  reverts  to  the  hoard¬ 
ing  state. 

While  connected,  Venus  is  in  the  hoarding  state.  U  pon  dis¬ 
connection,  it  enters  the  emulating  state  and  stays  there  until 
successfully  reconnected  to  a  server.  It  then  transits  temporar¬ 
ily  to  the  reintegrating  state,  and  thence  to  the  hoarding  state, 
where  it  resumes  connected  operation. 

W  hile  disconnected,  V enus  ser¬ 
vices  file  system  requests  by  relying 
solely  on  the  contents  of  its  cache. 

Since  cache  misses  cannot  be  ser¬ 
viced  or  masked,  they  appear  as 
failures  to  application  programs 
and  users.  The  persistence  of 
changes  made  while  disconnected 
is  achieved  via  an  operation  log, 
called  the  change  modify  log  (C ML  ), 
implemented  on  top  of  a  transac¬ 
tional  facility  called  the  recoverable 
virtual  memory  (RVM)  [6,  7], 

V  enus  implements  a  number  of 
optimizations  to  reduce  the  size  of 
the  CM  L.  Before  a  log  record  is 
appended  to  the  CML,  Venus 
checks  if  it  cancels  or  overrides  the 
effect  of  earlier  records.  For  exam¬ 
ple,  consider  the  create  of  a  file, 
followed  by  a  store.  I f  they  are 


followed  by  an  unlink,  all  three 
CML  records  and  the  data  associ¬ 
ated  with  the  store  can  be  elimi¬ 
nated.  Both  trace-driven  simulations 
and  measurements  of  Coda  in  actu¬ 
al  use  confirm  the  effectiveness  of 
log  optimizations  [4,  8], 

Venus  combines  implicit  and 
explicit  sources  of  information  into 
a  priority-based  cache  management 
algorithm.  The  implicit  information 
consists  of  recent  reference  history, 
as  in  least  recently  used  (LRU  ) 
caching  algorithms,  Explicit  infor¬ 
mation  takes  the  form  of  a  per- 
client  hoard  database  ( H  D  B ) , 
whose  entries  are  pathnames  iden¬ 
tifying  objects  of  interest  to  the 
user  at  that  client.  A  simple  front- 
end  program  called  hoard  allows  a  user  to  update  the  FI  DB 
directly  or  via  command  scripts  called  hoard  profiles.  V  enus 
periodically  reevaluates  which  objects  merit  retention  in  the 
cache  via  a  process  known  as  hoard  walking. 

Conflict  Detection  and  Resolution  —  Coda  addresses  the 
problem  of  concurrent  partitioned  updates  using  an  optimistic 
replica  control  strategy.  This  offers  the  highest  degree  of 
availability,  since  data  can  be  updated  in  any  network  parti¬ 
tion.  U  pon  reintegration,  the  system  ensures  detection  of  con¬ 
flicting  updates  and  provides  mechanisms  to  help  users 
recover  from  these  situations. 

Coda  uses  different  strategies  for  handling  concurrent  updates 
on  directories  and  files  [9],  F or  directories,  V  enus  possesses 
enough  semantic  knowledge  to  attempt  transparent  resolution 
of  conflicts.  Resolution  fails  only  if  a  newly  created  name  col¬ 
lides  with  an  existing  name,  if  an  object  updated  at  the  client 
or  the  server  has  been  deleted  by  the  other,  or  if  directory 
attributes  have  been  modified  at  the  server  and  the  client  [10], 
Since  U  N  I X  treats  files  as  un interpreted  byte  streams, 
Coda  does  not  possess  sufficient  semantic  knowledge  to 
resolve  file  conflicts.  R  ather,  it  offers  a  mechanism  for 
installing  and  transparently  invoking  application-specific 
resolvers  (A  SR  s)  [11].  A  n  A  SR  is  a  program  that  encapsulates 
the  detailed,  application-specific  knowledge  necessary  to  dis¬ 
tinguish  genuine  inconsistencies  from  reconcilable  differences. 
Appointment  calendars,  electronic  checkbooks,  and  project 
diaries  are  examples  of  applications 
where  an  application-specific 
approach  to  conflict  resolution  can 
have  big  payoffs.  If  an  ASR  is 
unsuccessful,  the  inconsistency  is 
exposed  to  the  user  for  manual 
repair. 

When  the  manual  repair  tool  is 
run  on  a  client,  V  enus  presents  the 
illusion  of  an  in-place  "explosion" 
of  inconsistent  objects  into  their 
distinct  versions.  Since  inconsisten¬ 
cies  appear  as  read-only  subtrees  in 
the  existing  name  space,  U  N IX  util¬ 
ities  such  as  diff  and  grep  can 
be  used  to  construct  appropriate 
replacements  for  the  inconsistent 
objects.  U  pon  completion  of  repair, 
the  exploded  subtrees  are  col¬ 
lapsed,  thus  reverting  to  a  normal 
name  space. 


■  Figure  2.  Venus  state  and  transitions  for  discon¬ 
nected  operation. 


■  Figure  3.  Venus  states  and  transitions  for  exploit¬ 
ing  weak  connectivity 
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Weakly  Connected  Operation 

Weak  connectivity,  in  the  form  of  intermittent,  low-bandwidth, 
or  expensive  networks,  is  a  fact  of  life  in  mobile  computing. 
D  isconnected  operation  can  be  viewed  as  the  extreme  case  of 
weakly  connected  operation  —  the  mobile  client  is  effectively 
using  a  network  of  zero  bandwidth  and  infinite  latency.  H  ow- 
ever,  although  disconnected  operation  is  viable,  it  is  not  a 
panacea.  A  disconnected  client  suffers  from  many  limitations: 

•  U  pdates  are  not  visible  to  other  clients. 

•  Cache  misses  may  impede  progress. 

•  U  pdates  are  at  risk  due  to  theft,  loss,  or  damage. 

•  U  pdate  conflicts  become  more  likely. 

•  Exhaustion  of  cache  space  is  a  concern. 

We  have  implemented  a  series  of  modifications  to  Coda 
that  alleviate  these  limitations  by  exploiting  weak  connectivity 
[12].  Our  modifications  span  a  number  of  areas.  At  the  lowest 
level,  the  transport  protocol  has  been  extended  to  be  robust, 
efficient,  and  adaptive  over  a  wide  range  of  network  band- 
widths.  M  odifications  at  the  higher  levels  include  those  need¬ 
ed  for  rapid  cache  validation  after  an  intermittent  failure,  for 
background  propagation  of  updates  over  a  slow  network,  and 
for  user-assisted  servicing  of  cache  misses  when  weakly  con¬ 
nected. 

Rapid  Cache  Validation  —  C  oda's  original  technique  for 
cache  coherence  while  connected  was  based  on  callbacks  [1, 
2],  When  a  client  is  disconnected,  it  can  no  longer  rely  on  call¬ 
backs.  U  pon  reconnection,  it  must  validate  all  cached  objects 
before  use  to  detect  updates  at  the  server.  U  nfortunately,  the 
time  for  this  validation  can  be  substantial  on  a  slow  network. 

0  ur  solution  allows  clients  to  track  server  state  at  multiple 
levels  of  granularity.  A  server  now  maintains  version  stamps 
for  each  of  its  volumes,  in  addition  to  stamps  on  individual 
objects.  When  an  object  is  updated,  the  server  increments  the 
version  stamp  of  the  object  and  that  of  its  containing  volume. 
Clients  cache  volume  version  stamps  in  anticipation  of  discon¬ 
nection. 

W  hen  connectivity  is  restored  after  a  network  failure,  the 
client  presents  volume  stamps  for  validation.  If  a  volume 
stamp  is  still  valid,  so  is  every  object  cached  from  that  volume. 
I  f  a  volume  stamp  is  not  valid,  cached  objects  from  the  vol¬ 
ume  must  be  validated  individually.  Even  in  this  case,  perfor¬ 
mance  is  no  worse  than  in  the  original  scheme.  Controlled 
experiments  as  well  as  measurements  from  Coda  in  actual  use 
confirm  that  this  approach  dramatically  improves  the  speed  of 
cache  validation. 

Trickle  Reintegration  —  T rickle  reintegration  is  a  mechanism 
that  propagates  updates  to  servers  asynchronously,  while 
minimally  impacting  foreground  activity.  Supporting  trickle 
reintegration  required  major  modifications  to  the  structure 
of  V enus,  A s  depicted  in  F ig.  2,  reintegration  was  originally 
a  transient  state  through  which  Venus  passed  en  route  to 
the  hoarding  state.  Since  reintegration  is  now  an  ongoing 
background  process,  the  transient  state  has  been  replaced  by 
a  stable  one  called  the  write-disconnected  state.  Figure  3 
shows  the  new  states  of  V  enus  and  the  main  transitions 
between  them. 

T rickle  reintegration  reduces  the  effectiveness  of  log  opti¬ 
mizations,  because  records  are  propagated  to  the  server  earli¬ 
er  than  when  disconnected;  thus,  they  have  less  opportunity  to 
be  eliminated  at  the  client.  A  good  design  must  balance  two 
factors,  0  n  one  hand,  records  should  spend  enough  time  in 
the  C  M  L  for  optimizations  to  be  effective.  0  n  the  other  hand, 
updates  should  be  propagated  to  servers  with  reasonable 
promptness.  Our  solution,  illustrated  in  Fig.  4,  uses  a  simple 
technique  based  on  aging.  A  record  is  not  eligible  for  reinte- 


Reinteg  ration 
barrier 


■  Figure  4.  CML  during  trickle  reintegration. 


gration  until  it  has  spent  a  minimal  amount  of  time  in  the 
CM  L.  This  amount  of  time,  called  the  aging  window  (A)  estab¬ 
lishes  a  limit  on  the  effectiveness  of  log  optimizations.  Based 
on  the  results  of  trace-driven  simulations,  we  have  set  the 
default  value  of  A  to  10  min. 

At  the  beginning  of  reintegration,  a  logical  divider  called 
the  reintegration  barrier  is  placed  in  the  C  M  L .  D  uring  reinte¬ 
gration,  which  may  take  a  while  on  a  slow  network,  the  por¬ 
tion  of  the  C  M  L  to  the  left  of  the  reintegration  barrier  is 
frozen.  0  nly  records  to  the  right  are  examined  for  optimiza¬ 
tion.  If  reintegration  is  successful,  the  barrier  and  all  records 
to  its  left  are  removed.  If  a  network  or  server  failure  causes 
reintegration  to  be  aborted,  the  barrier  as  well  as  any  records 
rendered  superfluous  by  new  updates  are  removed. 

Reintegrating  all  records  older  than  A  in  one  chunk  could 
saturate  a  slow  network  for  an  extended  period.  The  perfor¬ 
mance  of  a  concurrent  high-priority  network  event,  such  as 
servicing  a  cache  miss,  could  then  be  severely  degraded.  T o 
avoid  this  problem,  we  have  made  the  reintegration  chunk 
size  adaptive,  thus  bounding  the  duration  of  degradation.  If  a 
file  is  very  large,  we  transfer  it  as  a  series  of  fragments,  each 
smaller  than  the  currently  acceptable  chunk  size.  If  a  failure 
occurs,  file  transfer  is  resumed  after  the  last  successful  frag¬ 
ment. 

User-Assisted  Cache  Miss  Handling  —  W  hen  weakly  connect¬ 
ed,  the  performance  impact  of  cache  misses  is  often  too 
large  to  ignore.  I  n  many  cases,  a  user  would  rather  be  told 
that  a  large  file  is  missing  than  be  forced  to  wait  for  it  to  be 
fetched  over  a  weak  connection.  FI  owever,  there  are  also  situ¬ 
ations  where  a  file  is  so  critical  that  a  user  is  willing  to  suffer 
considerable  delay.  We  refer  to  the  maximum  time  a  user  is 
willing  to  wait  for  a  particular  file  as  his  patience  threshold  for 
that  file. 

Coda  incorporates  a  user  patience  model  to  provide  adap¬ 
tivity  in  cache  miss  handling.  This  model  helps  maintain 
u sa bility  at  all  bandwidths  by  balancing  two  factors  that 
intrude  on  transparency.  At  very  low  bandwidths,  the  delays  in 
fetching  large  files  annoy  users  more  than  the  need  for  inter¬ 
action.  As  bandwidth  rises,  delays  shrink  and  interaction 
becomes  more  annoying.  T o  preserve  usability,  Coda  handles 
more  cases  transparently.  I  n  the  limit,  at  strong  connectivity, 
cache  misses  are  fully  transparent. 

Our  initial  user  patience  model  is  logarithmic,  based  on 
the  conjecture  that  patience  is  similar  to  other  human  pro¬ 
cesses  such  as  vision.  F  igure  5  illustrates  this  model.  Rather 
than  expressing  the  patience  threshold  in  terms  of  seconds,  we 
have  converted  it  into  the  size  of  the  largest  file  that  can  be 
fetched  in  that  time  at  a  given  bandwidth.  If  the  estimated 
cache  miss  service  time  for  a  file  is  below  its  patience  thresh¬ 
old,  V  enus  services  the  miss  transparently;  otherwise,  V  enus 
reports  the  miss  by  returning  an  error.  At  any  time,  users  can 
examine  the  history  of  recent  cache  misses  and  augment  the 
hoard  database  appropriately.  They  can  also  interactively  con¬ 
trol  the  files  fetched  in  hoard  walks. 
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Isolation- Only  Transactions 

Coda's  emulation  of  the  U  N IX  file  system  model  has  the  ben¬ 
efit  of  compatibility  with  existing  applications.  U  nfortunately, 
the  U  NIX  model  is  weak  in  terms  of  consistency  support  for 
concurrent  file  accesses.  I  n  particular,  UNIX  has  no  notion  of 
read-write  file  conflicts.  This  deficiency  becomes  especially 
acute  in  mobile  computing,  because  extended  periods  of  dis¬ 
connected  or  weakly  connected  operation  may  increase  the 
probability  of  read-write  inconsistencies. 

Consider,  for  example,  a  CEO  using  a  disconnected  laptop 
to  work  on  a  report  for  an  upcoming  shareholder's  meeting. 
Before  disconnection  he  caches  a  spreadsheet  with  the  most 
recent  budget  figures  available.  H  e  writes  his  report  based  on 
the  numbers  in  that  spreadsheet.  D  uring  his  absence  new  bud¬ 
get  figures  become  available,  and  the  server's  copy  of  the 
spreadsheet  is  updated.  W  hen  the  C  E  0  returns  and  reinte¬ 
grates,  he  needs  to  discover  that  his  report  is  based  on  stale 
budget  data.  Note  that  this  is  not  a  write-write  conflict,  since 
no  one  else  has  updated  his  report;  it  is  a  read-write  conflict, 
between  the  spreadsheet  and  the  report.  No  UNIX  system  has 
the  ability  to  detect  and  deal  with  such  problems. 

We  have  extended  Coda  with  a  new  mechanism  called  iso¬ 
lation-only  transactions  (iOTs)  to  alleviate  this  shortcoming 
[13].  The  I OT  mechanism  offers  improved  consistency  for 
applications  in  a  convenient  and  easy-to-use  fashion.  The 
mechanism  is  efficient,  minimally  demanding  of  resource-poor 
mobile  clients,  and  upward-compatible  with  existing  UNIX 
software. 

An  I  OT  is  a  sequence  of  file  operations  that  are  treated  as 
a  unit  for  purposes  of  conflict  detection  and  resolution.  The 
name  stems  from  the  fact  that  this  mechanism  focuses  solely 
on  the  isolation  aspect  of  the  classic  ACID  transactional  prop¬ 
erties  [14].  In  other  words,  I OTs  do  not  guarantee  failure 
atomicity  and  only  conditionally  guarantee  permanence.  The 
I  OT  subsystem  of  V  enus  performs  automatic  read-write  con¬ 
flict  detection  based  on  certain  serializability  constraints.  It 
supports  a  variety  of  conflict  resolution  mechanisms  such  as 
reexecution  and  the  use  of  A  SR  s. 

Coda  provides  two  ways  to  use  IOTs.  U  sers  can  use  a  spe¬ 
cial  IOT  shell  to  transactional ly  encapsulate  selected  unmodi¬ 
fied  UNIX  applications.  A  I  ter  natively,  they  can  modify 
applications  using  the  I  OT  programming  interface.  Figure  6 
shows  an  example  of  the  use  of  IOTs  in  Coda. 

Status  and  Experience 

Evolution  —  Disconnected  operation  in  Coda  was  implement¬ 
ed  over  a  period  of  two  to  three  years.  A  version  of  discon¬ 


nected  operation  with  minimal  functionality  was  demonstrat¬ 
ed  in  October  1990.  A  more  complete  version  was  functional 
in  early  1991  and  has  been  used  since  then  by  members  of  the 
Coda  project. 

Work  on  the  extensions  for  weak  connectivity  began  in 
1993.  The  transport  protocol  extensions  and  rapid  cache  vali¬ 
dation  mechanism  have  been  in  regular  use  for  over  a  year. 
The  trickle  reintegration  and  user  advice  mechanisms  were 
implemented  between  1994  and  early  1995,  and  have  recently 
been  released  for  general  use. 

A  prototype  implementation  of  IOT  support  in  Coda  has 
been  completed.  A  n  evaluation  of  this  prototype  based  on 
controlled  experiments  confirms  that  the  resource  demands  of 
I  OTs  are  indeed  acceptable  in  a  mobile  environment.  This 
prototype  now  awaits  more  extensive  use. 

Current  Deployment  —  C oda  is  currently  deployed  to  a  user 
community  of  Coda  developers  and  other  computer  science 
researchers.  Our  deployment  is  currently  on  M  ach  2.6,  but  we 
are  porting  Coda  to  NetBSD.  We  have  over  40  user  accounts, 
of  which  about  25  are  used  regularly.  M  any  users  run  Coda  on 
both  their  desktop  workstations  and  their  laptops.  W  e  have  a 
total  of  about  35  Coda  clients,  evenly  divided  between  work¬ 
stations  and  laptops.  The  laptops  are  486-based  DEC  425SLs 
and  I B  M  ThinkPad  701Cs,  while  the  workstations  are  mostly 
D  EC  Station  5000/200s.  These  clients  access  almost  4  G  B  of 
data  stored  on  Coda  servers.  I  ndeed,  there  are  many  more 
people  wishing  to  use  Coda  than  we  can  accommodate  with 
hardware  or  support  services. 

Empirical  Study  —  How  will  people  use  mobile  computing? 
The  answer  to  this  question  is  important  because  it  will  criti¬ 
cally  influence  future  designs  of  mobile  computing  systems.  As 
a  first  step  in  answering  this  question,  we  have  instrumented 
our  deployed  Coda  system  and  have  been  conducting  an 
ongoing  empirical  study  of  system  and  user  behavior  [8]. 

0  ur  data  shows  that  Coda  clients  do  experience  various 
kinds  of  service  failures,  but  that  Coda  is  able  to  mask  these 
failures  effectively.  Our  observations  confirm  many  earlier 
simulation-based  predictions  on  resource  usage,  as  well  as 
many  anecdotal  reports  from  our  user  community.  Our  study 
has  also  produced  some  surprises.  For  example,  the  number 
of  transient  failures  observed  has  been  far  larger  than  antici¬ 
pated.  A  nother  surprise  is  the  tendency  of  users  to  limit  muta¬ 
tion  activity  while  voluntarily  disconnected. 

Source  Code  Distribution  —  Since  1992  Coda  has  been  dis¬ 
tributed  in  source  code  form  to  several  sites  outside  of 
Carnegie  M  el  I  on  U  niversity.  Porting  Coda  to  a  new  machine 
type  has  proven  to  be  relatively  straightforward.  M  ost  of  the 
code  is  outside  the  kernel.  The  only  in-kernel  code,  a  virtual 
file  system  (V  F S)  driver  [15],  is  small  and  entirely  machine- 
independent.  Porting  simply  involves  recompiling  the  Coda 
client  and  server  code,  and  ensuring  that  the  kernel  works  on 
the  specific  piece  of  hardware. 


Odyssey:  Application 
Aware  Adaptation 


m  Ithough  the  viability  of  application-transparent  adapta- 
M\  tion  has  been  demonstrated  by  Coda,  there  are  impor- 
tant  situations  where  it  is  inadequate.  This  is  likely  to  be 
especially  true  of  applications  involving  multimedia  data  such 
as  videos  and  maps.  F  urthermore,  the  Coda  approach  relies 
heavily  on  caching,  and  is  likely  to  fall  short  when  there  is  no 
temporal  locality  to  exploit.  This  situation  is  likely  to  arise  in 
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iot  40  accessed  the  following  invalid  objects! 

/c  oda/us  r/1  uqi  /deroo/*  1  i bfi  386_/if»ac h/1  i buti  1  ♦  a  <0 x7f  0  0  0  279*  1  eb&+  4«b65 
resolue  iot  40  via  automatic  reexecution 
c  d  /c  oda/us  iVl  u-qi  /demo^ob j  s /@s  ys  /» tool  s 

CC  -9  — S  -o  cfs  cfs  +  o  /coda/project/coda/alpha/lib/pioc tl  +  o  /coda^u 

s  r/1  u-qi  /'demo/l  i  b/1  i  but  i  1  ♦  a 

***  Using  ffT&T  C++  Version  3+0  *«« 

/usrAs/bin/cc  -L/ats/c5+cmu+edu/mi5c/c++/@5y5/alpha/lib  -o  cfs  -g 
-g  cfs  +  o  /coda/projec  tVcoda/alpha/lib/pioctl  +  o  /c  oda/usr/lu-qi  /demo/li 
b/libutil+a  -1C 

iot  40  resolution  succeeded 

iot  41  is  succesfully  reintegrated 
finish  time  is  Sat  Nov  19  00=06!46  1994 
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[TEHPESTivtools]}88  cfs  disconnect  1 
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cd  /coda/usr/luo|i/demo/objs/(?sys/vtools  | 

CC  -g  -g  -o  cfs  cfs.o  /coda/project/coda/alpha/l  ib/pioctl .o  /coda/usr/ luo|i /demo/ 1  ib/1  i  but  i  1  .a  | 

kxh  Using  AT&T  C++  Version  3.0  xxx  | 

/usr/cs/bin/cc  -L/afs/cs,crnu.edu/misc/c++/<?sys/al|oha/lib  -o  cfs  -g  -g  cfs.o  /coda/project/coda/alp  jj 
ha/1 ib/pioctl .o  /coda/usr/lu°|i/demo/lib/l  lbuti  l.a  -1C  | 

[ TEMPEST { vtoo 1 s 1 ! 91  cd  /coda/usr/ luyi /demo/ doc  ;  latex  paper.tex  | 

This  is  TeX,  C  Version  2.991  (no  format  preloaded) 

C  |®'3p@ln'  *  t©X 

LaTeX  Version  2.09  <24  May  1989> 

C /usr/m i sc/ , tex/ 1 i b/macr os//art icle.sty 
Document  Style  'article'  <16  Mar  88>* 

C /usr/m i sc/ ,  tex/ 1  i  b/macr cs//artll .  sty > )  ( /usr/m  i  sc/ .  tex/ 1  i  b/macros//t i mes  . sty 
C/usr/misc/,tex/lib/macros//psfonts,sty)>  (paper.aux)  Cl]  C21  [31  [4] 

(paper, bbl  [5])  [6]  (paper.aux) 

Output  written  on  paper. dvi  (6  pages,  24380  bytes). 
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[TEMPEST! docii 92  It 


TID 

STATE 

41 

PENDING 

40 

PENDING 

[ TEMP  EST ; doc ] ! 93  « 

C  TEMPEST ! doc ] ! 94 

TID 

STATE 

41 

COMMITTED 

40 

RESOLVED 

[ TEMPEST ! doc ] ! 95  Q 


COMMAND 

/usr/misc/bin/latex  paper.tex 
/usr/cs/b in/make  cfs 


COMMAND 

/usr/misc/bin/latex  paper.tex 
/usr/cs/b in/make  cfs 


\  Figure  6.  Example  of  IOT  usage. 


scenarios  involving  the  search  of  data  repositories  from 
mobile  clients. 

W e  are  exploring  solutions  to  these  problems  in  the  con¬ 
text  of  Odyssey.  Our  approach  is  not  to  invent  a  new  operat¬ 
ing  system  but  to  extend  UNIX  with  a  small  but  powerful  set 
of  extensions  for  mobile  computing.  I  n  keeping  with  this  mini¬ 
malist  philosophy,  we  also  strive  to  keep  changes  to  existing 
applications  small  and  consistent  with  the  U  N I X  program¬ 
ming  idiom.  Since  application  transparency  is  a  degenerate 
case  of  application  awareness,  we  expect  to  eventually  incor¬ 
porate  Coda  as  part  of  Odyssey.  H  owever,  the  initial  develop¬ 
ment  of  the  two  systems  is  proceeding  along  separate  paths. 

Support  for  Application-Aware  Adaptation 

The  need  for  application-aware  adaptation  can  be  seen  from  a 
simple  example.  Consider  a  movie  player  capable  of  display¬ 
ing  stored  video  images.  Below  a  certain  bandwidth  and  net¬ 
work  quality,  it  will  not  be  possible  for  the  player  to  display 
the  images  in  full-motion  color.  Extensive  compression  will 
help,  but  cannot  solve  the  problem  completely.  H  owever,  if 
the  application  is  also  capable  of  displaying  the  image  in  slow- 
scan  black  and  white,  it  could  automatically  do  so  when  band¬ 
width  falls  below  a  critical  threshold. 

Fidelity  —  That  slow-scan  black-and-white  display  is  a  reason¬ 
able  form  of  degradation  is  specific  to  video  data.  Other  data 
types  may  have  entirely  different  forms  of  degradation  that 
are  meaningful  to  them.  For  example,  increasing  the  mini¬ 
mum  feature  size  displayed  may  be  an  appropriate  form  of 


degradation  for  map  data.  W  e  define  fidelity  as  the  degree  to 
which  a  copy  of  data  presented  for  use  at  a  client  matches  the 
reference  copy  at  a  server.  Fidelity  has  many  dimensions.  One 
well-known  universal  dimension  is  consistency;  other  dimen¬ 
sions  depend  on  the  type  of  data  in  question.  The  dimensions 
of  fidelity  are  natural  axes  of  adaptation  for  mobility.  But  the 
adaptation  cannot  be  determined  solely  by  the  type  of  data;  it 
also  depends  on  the  application.  For  example,  if  the  applica¬ 
tion  were  a  video  editor  rather  than  a  video  player,  slowing 
the  frame  rate  would  be  a  more  appropriate  form  of  degrada¬ 
tion  than  dropping  frames  to  preserve  the  frame  rate. 

Resource  Negotiation  API  —  Odyssey  provides  an  application 
programming  interface  (API)  for  resource  negotiation  [16], 
The  resources  in  question  may  be  generic,  such  as  network 
bandwidth,  cache  space,  processor  cycles,  or  battery  life. 
Resources  may  also  be  application-specific,  such  as  the  num¬ 
ber  of  queries  left  to  a  limited-subscription  stock  quotation 
service. 

A  n  application  initially  tries  to  access  data  at  the  highest 
level  of  fidelity.  If  the  resources  needed  for  this  exceed  what 
is  currently  available,  Odyssey  informs  the  application  of  this 
fact.  The  application  then  selects  a  fidelity  level  consistent 
with  available  resources.  It  also  registers  a  window  of  toler¬ 
ance  for  each  resource  of  interest.  At  a  later  time,  if  the  avail¬ 
ability  of  a  resource  improves  or  degrades  beyond  this  window, 
Odyssey  will  notify  the  application.  It  is  the  application's 
responsibility  to  then  renegotiate  the  resources  needed  for  an 
appropriate  level  of  fidelity. 
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Name  Space  and  Client  Structure  —  0  dyssey  provides  a  sin¬ 
gle  global  name  space  to  its  clients,  as  shown  in  F  ig.  7.  This 
name  space  is  broken  into  subspaces  called  tomes.  T omes  are 
conceptually  similar  to  volumes  in  Coda  and  A FS,  but  incor¬ 
porate  the  notion  of  type.  The  type  of  a  tome  determines  the 
type-specific  resources,  operations,  and  dimensions  of  fidelity 
for  all  items  in  the  tome. 

As  illustrated  in  Fig.  8,  the  structure  of  an  Odyssey  client 
reflects  the  decomposition  of  functionality  into  generic  and 
type-specific  components.  Generic  functionality  is  implement¬ 
ed  by  the  viceroy,  whose  most  important  task  is  to  act  as  the 
single  point  of  resource  control  in  the  system.  The  viceroy 
also  services  requests  for  generic  resources  and  plays  a  central 
role  in  resource  negotiation. 

T ype-specific  functionality  is  implemented  in  cache  man¬ 
agers  subordinate  to  the  viceroy,  called  wardens.  There  is  one 
warden  for  each  tome  type,  and  it  is  invoked  by  the  viceroy  to 
service  requests  on  Odyssey  objects  of  that  type.  The  wardens 
are  responsible  for  implementing  the  access  methods  on 
objects  of  their  type,  and  for  providing  support  for  different 
levels  of  fidelity.  They  also  provide  reasonable  default  policies 
to  allow  a  modicum  of  backward  compatibility  with  legacy 
applications. 

Support  for  Dynamic  Sets 

FI  ow  does  one  support  search  of  data  repositories  from 
mobile  clients  that  are  weakly  connected?  Since  there  is  little 
temporal  locality  to  exploit,  caching  is  unlikely  to  be  helpful. 

I  nstead,  our  approach  is  to  exploit  the  associativity  inherent  in 
search  operations  to  overlap  prefetching  of  data  over  slow 
networks  with  the  computation  or  think  time  involved  in  a 
search  task. 

The  vehicle  we  are  using  for  this  aspect  of  our  research  is  a 
new  operating  system  abstraction  called  dynamic  sets  [17,  18]. 
The  essence  of  the  abstraction  is  the  explicit  grouping  of  sets 
of  file  accesses  and  the  communication  of  this  grouping  by 
applications  to  the  operating  system.  This  simple  abstraction 
can  have  surprisingly  powerful  performance  implications  for 
mobile  search.  F  igure  9  presents  the  most  important  system 
calls  in  the  Odyssey  API  for  dynamic  sets. 

By  using  dynamic  sets,  an  application  discloses  the  mem¬ 
bership  of  a  group  of  related  files.  This  disclosure  offers  the 
system  a  strong  hint  on  future  file  accesses  that  can  be  exploit¬ 
ed  for  prefetching.  In  addition,  by  using  a  set  to  represent  the 
grouping,  the  system  is  free  to  optimize  the  order  in  which  the 
set  members  are  fetched.  For  example,  if  some  members  of 
the  set  happen  to  be  cached  they  can  be  returned  first.  The 
fetching  of  later  members  can  be  overlapped  with  the  process¬ 
ing  of  earlier  members. 


Status  and  Experience 

We  have  completed  a  simple,  skeletal  implementation  of  the 
Odyssey  architecture.  This  includes  a  library  implementation 
of  the  A  PI  for  application-aware  adaptation,  as  well  as  the 
wardens,  servers,  and  applications  for  video  and  map  data. 
A  Ithough  the  prototype  is  rudimentary  in  many  respects,  it 
provides  initial  evidence  of  the  overall  validity  of  our 
approach.  Based  on  this  positive  feedback,  we  are  implement¬ 
ing  a  more  complete,  in-kernel  prototype. 

0  ur  work  in  dynamic  sets  has  gone  through  two  phases.  I  n 
the  first  phase,  we  built  a  user-level  library  implementation  of 
the  dynamic  sets  A  PI .  A  Ithough  the  prototype's  absolute  per¬ 
formance  was  modest  due  to  implementation  inefficiencies,  it 
was  adequate  to  confirm  the  substantial  benefits  of  dynamic 
sets.  We  codified  our  experience  into  a  validated  perfor¬ 
mance  model,  and  used  it  to  explore  whether  the  effort  of  a 
more  complete  and  efficient  implementation  of  dynamic  sets 
was  justified.  Based  on  the  encouraging  results  of  our  analy¬ 
sis,  we  have  embarked  on  the  second  phase  and  are  close  to 
completing  an  in-kernel  implementation  of  dynamic  sets. 

Conclusion 

Our  work  bears  a  complementary  relationship  to  the 
other  efforts  described  in  this  special  issue.  M  obile  IP, 
described  byj  ohnson  and  M  altz  [19],  represents  a  net¬ 
working  layer  below  Coda  and  Odyssey.  The  different  quality 
streams  of  G  enerative  V  ideo,  described  by  M  oura  et  ai.  [20], 
correspond  to  different  levels  of  video  fidelity  on  an  Odyssey 
client.  The  applications  described  by  Bruegge  and  Bennington 
[21]  could  benefit  from  Coda's  support  for  mobile  file  access. 
The  W  ireless  A  ndrew  N  etwork  described  by  FI  ills  and  J  ohn¬ 
son  [22]  provides  the  infrastructure  necessary  for  the  Coda 
user  community  to  remain  connected  while  mobile.  Finally, 
the  wearable  computers  described  by  Smailagic  and  Siewiorek 
[23]  are  now  powerful  enough  to  run  Coda,  thus  enabling  a 
new  and  unique  class  of  applications. 

The  ability  to  access  information  on  demand  while  mobile 
will  be  a  critical  capability  in  the  21st  century.  As  elaborated 
in  this  article,  adaptation  is  the  key  to  this  capability.  Our 
research  is  exploring  two  different  approaches  to  adaptation: 
application-transparent  and  application-aware.  Our  experi¬ 
ence  with  Coda  confirms  that  application-transparent  adapta¬ 
tion  is  indeed  effective  in  many  cases.  I  n  circumstances  where 
it  is  inadequate,  our  initial  experience  with  Odyssey  suggests 
that  application-aware  adaptation  is  the  appropriate  strategy. 
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setHandle  setOpen(char  *setPathname)  ; 

errorCode  setCIOSe ( setHandle  set)  ; 

fileDesc  setlterate( setHandle  set,  int  flags)  ; 

errorCode  setDigest(setHandle  set,  char  *buf,  int  count)  ; 

A  dynamic  set  is  created  by  calling  setOpen  with  a  set  pathname,  and  receiv¬ 
ing  a  set  handle  for  the  open  set  in  return.  The  system  can  expand  the  set  into 
its  members  and  fetch  these  members  as  agressively  as  resources  warrant. 
Once  open,  the  membership  of  a  set  can  be  browsed  using  setDigest.  An 
individual  member  can  be  accessed  using  setlterate,  which  returns  a  file 
descriptor  as  if  an  open  had  been  performed  on  the  member  selected.  The 
system  is  free  to  iterate  through  the  set  in  any  order.  setClose  terminates  use 

■  Figure  9.  Core  subset  of  dynamic  sets  API . 
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Further  Reading 

This  article  provides  only  the  briefest  overview  of 
our  work.  A  detailed  annotated  guide  to  Coda 
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W  ide  W eb  at  this  U  R  L :  http://www.cs.cmu.edu/afs/ 
cscmu.edu/project/coda/Web/coda.html. 
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